apps/web/lib/zod/schemas/partners.ts (1)

731-753: Schema looks solid overall; one nit on the dedup + count check.

The superRefine deduplicates before counting, but the .max(50) on the emails array (line 736) applies before the superRefine runs — so if someone sends 50 emails in the array plus a different email, the array check passes but the combined unique set is 51, and the superRefine correctly catches it. This is fine and consistent.

However, note that neither email nor emails is required at the schema level — both are optional. The server action guards against an empty set at runtime (line 34-36 of invite-partner.ts), but adding a schema-level refinement for "at least one recipient" would give earlier, more descriptive Zod errors. Not blocking since the action handles it.

apps/web/lib/actions/partners/invite-partner.ts (1)

184-196: Sequential enrollment — consider batching for large invite lists.

Partners are enrolled one-at-a-time in a for loop. For up to 50 recipients, this means 50 serial DB round-trips. While acceptable for small batches, this could result in noticeable latency at higher counts. No immediate fix needed, but worth noting for future optimization (e.g., parallel batches of 5-10).

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/invite-partner-sheet.tsx (2)

323-361: emailInput is processed twice — once by commitEmailInput and again inline. Works due to React batching but is fragile.

commitEmailInput() at line 328 adds parsed emails to recipientEmails state and clears emailInput — but since React batches state updates, neither change is reflected synchronously. Lines 334-342 then re-parse emailInput to build finalRecipientEmails. This works today because state is stale within the same handler, but it's subtle and would break if the function were made async before line 334, or if commitEmailInput were refactored.

Consider having commitEmailInput return the committed emails directly so onSubmit can use them without re-parsing.

Sketch

- const commitEmailInput = () => {
+ const commitEmailInput = (): string[] | false => {
     const emailCandidates = emailInput
       .split(",")
       .map((value) => value.trim())
       .filter(Boolean);

     if (emailCandidates.length === 0) {
       setEmailInput("");
-      return true;
+      return [];
     }

+    const committed: string[] = [];
     for (const candidate of emailCandidates) {
       const wasAdded = addRecipientEmail(candidate);
       if (!wasAdded) {
         return false;
       }
+      committed.push(candidate.trim().toLowerCase());
     }

     setEmailInput("");
-    return true;
+    return committed;
   };

Then in onSubmit:

-    const didCommitPendingInput = commitEmailInput();
-    if (!didCommitPendingInput) {
+    const committed = commitEmailInput();
+    if (committed === false) {
       return;
     }
-    const finalRecipientEmails = Array.from(
-      new Set([
-        ...recipientEmails,
-        ...emailInput
-          .split(",")
-          .map((value) => value.trim().toLowerCase())
-          .filter(Boolean),
-      ]),
-    );
+    const finalRecipientEmails = Array.from(
+      new Set([...recipientEmails, ...committed]),
+    );

---

217-218: Prefer ?? 1 over || 1 for invitedCount fallback.

|| 1 would coerce a legitimate invitedCount of 0 to 1. While 0 shouldn't occur given server validation, ?? is more precise and conveys the intent of "default only if nullish."

Proposed fix

-      const invitedCount = data?.invitedCount || 1;
+      const invitedCount = data?.invitedCount ?? 1;

packages/ui/src/index.tsx (1)

26-27: Nit: export ordering — multi-value-input should come after menu-item.

The surrounding exports are alphabetically sorted. Since "menu-item" < "multi-value-input" lexicographically, these two lines should be swapped to maintain consistency.

Proposed fix

-export * from "./multi-value-input";
 export * from "./menu-item";
+export * from "./multi-value-input";

packages/ui/src/multi-value-input.tsx (2)

137-157: Consider separating the ResizeObserver setup from the manual checkWrapped call.

The [values, inputValue] dependencies cause the observer to be torn down and recreated on every keystroke and chip change. The observer only needs to be created once; the manual checkWrapped() call is what needs to re-run when values change.

Sketch

+ // Manual re-check when content changes
+ useEffect(() => {
+   const container = containerRef.current;
+   if (!container) return;
+   const children = Array.from(container.children) as HTMLElement[];
+   if (children.length <= 1) { setIsWrapped(false); return; }
+   const tops = children.map((el) => el.offsetTop);
+   const firstRowTop = Math.min(...tops);
+   setIsWrapped(tops.some((top) => top - firstRowTop > 2));
+ }, [values, inputValue]);
+
+ // ResizeObserver — mount once
  useEffect(() => {
    const container = containerRef.current;
    if (!container) return;
-
    const checkWrapped = () => {
      const children = Array.from(container.children) as HTMLElement[];
-     if (children.length <= 1) {
-       setIsWrapped(false);
-       return;
-     }
+     if (children.length <= 1) { setIsWrapped(false); return; }
      const tops = children.map((el) => el.offsetTop);
      const firstRowTop = Math.min(...tops);
      setIsWrapped(tops.some((top) => top - firstRowTop > 2));
    };
-
-   checkWrapped();
    const observer = new ResizeObserver(checkWrapped);
    observer.observe(container);
    return () => observer.disconnect();
- }, [values, inputValue]);
+ }, []);

---

67-84: Optional: With React 19, forwardRef is no longer needed.

Since this project uses React 19.1.3, ref can be received as a regular prop. The forwardRef wrapper still works but is the legacy pattern.

Sketch (React 19 style)

-const MultiValueInput = React.forwardRef<
-  MultiValueInputRef,
-  MultiValueInputProps
->(function MultiValueInput(
-  { values, onChange, placeholder, id, className, inputClassName, disabled, normalize = (v) => v.trim(), maxValues, autoFocus },
-  ref,
-) {
+function MultiValueInput({
+  values, onChange, placeholder, id, className, inputClassName, disabled,
+  normalize = (v) => v.trim(), maxValues, autoFocus, ref,
+}: MultiValueInputProps & { ref?: React.Ref<MultiValueInputRef> }) {
   // ... component body unchanged
-});
-MultiValueInput.displayName = "MultiValueInput";
+}

packages/ui/src/multi-value-input.tsx (2)

91-106: addValues calls onChange with the original reference when all candidates are duplicates.

When all normalized candidates already exist in values, addValues returns the original values reference (line 97). Callers like handlePaste (line 223-224) then call onChange(next) with this same reference, triggering an unnecessary state update. Not a bug (React/react-hook-form handles same-reference sets gracefully), but worth noting.

---

138-157: ResizeObserver is recreated on every values/inputValue change.

The checkWrapped callback reads from the DOM, so the observer itself doesn't need to be recreated — only the immediate checkWrapped() call on line 153 needs to re-run. Consider splitting the observer setup (no deps) from the immediate check to avoid unnecessary observer churn.

apps/web/lib/zod/schemas/partners.ts (1)

739-743: Consider adding .min(1) to the emails array.

The schema currently allows an empty emails array. While the UI guards against this, the server action would silently proceed with zero work if called directly with emails: []. Other bulk schemas in this file (e.g., bulkApprovePartnersSchema at line 756) enforce .min(1).

Proposed fix

 export const bulkInvitePartnersSchema = z.object({
   workspaceId: z.string(),
   groupId: z.string().nullish(),
-  emails: z.array(z.email().trim().min(1).max(100)).max(50),
+  emails: z.array(z.email().trim().min(1).max(100)).min(1).max(50),
 });

apps/web/app/app.dub.co/(dashboard)/[slug]/(ee)/program/partners/invite-partner-sheet.tsx (1)

46-52: email field in InvitePartnerFormData is unused.

The email field is set via setValue in the onChange handler (line 300-303) but is never read in the onSubmit handler — finalEmails[0] is used instead. Consider removing it to reduce confusion.

packages/ui/src/multi-value-input.tsx (2)

108-118: onChange is called unconditionally even when no new values are added.

When all parsed values are already present, addValues returns the original values reference. Line 115 still calls onChange(next), triggering a no-op state update in the parent. Consider guarding with a reference check.

Proposed fix

   const commitPendingInput = useCallback((): string[] => {
     const parsed = parseCsvLikeValues(inputValue);
     if (parsed.length === 0) {
       setInputValue("");
       return values;
     }
     const next = addValues(parsed);
-    onChange(next);
+    if (next !== values) onChange(next);
     setInputValue("");
     return next;
   }, [inputValue, values, addValues, onChange]);

---

248-277: Chip elements are not keyboard-accessible on their own.

The <span> chips use onClick for selection but have no role, tabIndex, or keyboard event handlers. Users relying on assistive technology cannot interact with individual chips via click or focus. The keyboard navigation via the input element partially mitigates this, but the chips themselves are invisible to screen readers as interactive elements.